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Introduction 


UX theory and UX practice can be two different worlds. 


We have user-centered design and design thinking taught in tradi- 
tional UX programs. We have the fast-paced principles of Agile UX 
and Lean UX. And we have all the endless techniques in between that 


help us move from idea to validated design. 


What actually works? How do UX professionals and leaders really 


practice their craft in successful companies? 


In this guide, we’ll lift the curtain on UX design within some of to- 
day’s most successful companies. You’ll see a wide spectrum of UX 
processes ranging from informal activities to highly structured design 


techniques. 


As the co-founder of UXPin (a collaborative design platform), I’ve 
spoken with hundreds of from startups to large corporations to learn 
about their processes. I’ve seen that the best designers aren’t a slave 
to a single process. They build up a large toolbox of skills and pro- 
cesses, but they always adapt to the specific project constraints, user 


goals, and business goals. 
A few patterns, however, always emerge: 


¢ Collaboration beyond lip service — Whether it’s the kickoff or 


hi-fi prototyping, the whole product team involves stakeholders 


for ideas and feedback. A clear product lead then makes the call 


on which decisions to implement. 


e User-driven quality —- Teams conduct user research before the 
project, during the project, and sometimes even dogfood the prod- 


uct themselves. They always test the risky ideas. 


e Outcomes over outputs - Instead of acting as just a lagging indi- 
cator, every piece of documentation drives decisions. Teams are 


then freed up for more exploration and testing. 


While the exact execution differs based on the company, you'll see 
how top companies like Autodesk, Slack, Kaplan, Sumo Logic, and 


3M Health built their culture and processes on these same principles. 


Our team has distilled hours of interviews with each company into 


just the most practical methods. 


I hope this guide will help you continue building your toolbox to 


adapt to our changing world of design. 


ool 


Marcin Treder, CEO and co-founder of UXPin 


Discovery-Driven 
Enterprise UX Design 


Autodesk 


At Autodesk, the company’s design teams are as global as its customer 
base. The $2.5 billion-dollar software giant is powered by 7700 em- 


ployees across all 7 continents. 


In the Tel Aviv office, Uri Ashano serves as the senior UX manager for 
AutoCAD 360, the mobile application of the company’s flagship prod- 


uct. Uri and his team of five (two UX designers, two visual designers 


and one researcher) collaborate closely with the San Francisco HQ 


to practice user-centered design within an Agile process. 


As Uri explains, the company sees itself as a knowledge house, not 
just a software provider. All designers train and work with the 
Luma Innovation Institute, which teaches 36 different methods for 
user-centered design. The design process Uri and team follow each 
time they get new feature requests illuminates the power of collab- 


orative design, especially in the discovery stage. 


Research the Problem 


The Tel Aviv team’s process begins when they get a request from the 


larger AutoCAD 360 team for a new feature. 


The request usually presents itself as a user scenario such as: “An ar- 
chitect needs an AUTOCAD drawing at his job site. He’s bringing along 
an iPad (or other tablet) and wants to view his drawings, modify, and 
annotate. Afterwards, he wants to share the updates with colleagues.” 
In response, the team first opens a new project in Slack to start inves- 
tigating the problem the feature aims to solve. This initial research 
consists of interviewing local architect firms, reviewing customer 
support tickets for ideas, and reviewing online data in MixPanel. 
The team also consults data from the greater Autodesk’s research, 
mostly around multiplatform use of AutoCAD and the flows related 


to these products. 


“We always examine incoming request from a user-centric mindset,” 
Uri explains. “We pull out the low-hanging fruit and then focus on the 
riskier elements that we can go after. These user stories are always 


our starting point to design.” 


Deeper Discovery 


Once a vision for the feature(s) emerge, the team moves quickly into 
the discovery mode. This period of design is one of the most intense 
and collaborative for the team-—as Uri says, “we don’t want to lose 


any creative minds in the process”. 


Rather than sending designers off with specific projects, Uri engages 
all team members together to explore ideas. By exploring these ideas 
in half or full day workshops, the team collectively decides which are 
worth actually moving forward with as epics, breaking them down 


further into user stories. 


“Working together, we can get twenty great ideas in twenty minutes,” 
Uri says “Our collaborative brainstorming is far more effective than 


if we sent designers off to think on their own.” 


Using bullseye diagrams, pains vs. gains charts, and Impact vs. Fea- 
sibility matrices, the team starts to map out customer needs and 
prioritize ideas. As the ideas populate the different diagrams and 
charts, team members (including product managers and developers) 


also add smiley or sad faces next to the concepts. 
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Bullseye Diagram used by Autodesk 


Uri notes that the earlier they can ingrain developers and product 
managers in decision making, the better. In fact, this is why the teams 


are also physically located near each other, sharing meeting spaces 
and much time together. 


& 


Feasibility vs. Impact chart used by Autodesk 


From the team’s work with Luma Institute, they also use up to 10 other 
brainstorming methods such as affinity maps and eyeball diagrams. 
At this point in the process, sketching remains minimal with all the 


focus on idea generation through sticky notes. 


Only when there is firm agreement on the overall feature set will a 
designer start to sketch in greater detail. And, following the Agile UX 
process, the team will leave the stage of deep discovery with epics, 


user stories, and a backlog that they can revisit for more ideas. 


Designing the Solutions 


Once the rough feature sets are decided, the team holds a formal 


kickoff. From there, long brainstorms are replaced by focused daily 


stand-ups that involve only people essential to the work being done. 


Bundle and Fducation Notticabe 
Flow 3 - Student with facebook share 


User flow created in UXPin by Autodesk’s AutoCAD 360 team 


Once the team members divide to conquer their specific tasks, the 


group starts designing collaboratively with early wireframes and user 
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flows for each user story. Some designers create the wireframes in 
the platform, while others will import them from Sketch. To speed 
up the process for his team, Uri created templates in the platform to 


easily show the flow between 5-6 screens at a time. 


As the designers start mapping out their flows, the developers will 
also be wrapping up their technical research. To consolidate their 
knowledge, the AutoCAD 360 product team now creates a lightweight 
PRD that focuses on guidelines over prescriptions. The technical de- 
tails are contained in Dropbox and Zeplin links, while the interactive 


details are reflected in the links to the user flows. 


Bundle and Education Notification 
UX/UI Specifications 


PRD: hites://docs.google.com/document/d/14 TIASIUSchilkwOFcGclFTzi3hOnk5-pzu6F DIRr2xE/edit 
Zepiin iOS: Bundle and Education Notification - Android 

hitos://app.zeplin.jo/project. nimi#pid=56d2¢ 1 3a5cc45562 tedee7 14&dashboard 
Zeplin Android: Bundle and Education Notification - Android 


hites://ann.zenlin jo/orolect himitpid=56d2¢ 16322340d995976 laed&dashboard 


UX/UI Dropbox: UX Team > AutoCAD WS > Design > Mobile > v3.5 > Bundle and Education Notification 


Table of Contents 


Flow 1 - Bundle User 

Flow 2 - Student without share 

Flow 3 - Student with Facebook share 
Flow 4 - Student with Twitter share 
Flow 5 - Student with More share 
Flow 6 - Student with share and back 
Flow 7 - Chinese student share 

Flow 8 - Student with share error 


AutoCAD 360 / UX/UI Specifications 


Product Requirements Document created in UXPin by Autodesk’s AutoCAD 360 team 


“Annotating our user flows is very useful because it lets us get great 
feedback even in the early stages of conceptual design,” he says. “Ev- 


eryone can go in-including developers and product managers—and 


see how things are created in real-time. Also, since it is extremely 
hard to create mockups that show the behavior of an iPad, annota- 


tions are very helpful for our multi-device storytelling.” 


For feedback on the PRD and early concepts, the Tel Aviv team will 
also share their user flows with the larger AutoCAD 360 team in the 
U.S., Singapore and Germany. As the Tel Aviv team iterates their 
wireframes into higher fidelity mockups, they will also hold remote 


design reviews within the platform. 


Problem-Solving With Prototypes 


For most designs, the AutoCAD 360 team iterates most wireframes 
into static hi-fi mockups and then directly to code. In the interest of 
time, the team only creates prototypes for new interaction models 


or potentially problematic flows (e.g. ones with multiple transitions). 


The fidelity of the prototype depends on the design question. For 
example, Uri’s team will create lo-fi prototypes if they’re testing a 
totally new interaction model. On the other hand, they’ll create a 


hi-fi prototype if they’re testing branding or different color palettes. 


For usability testing, the AutoCAD 360 team general tests with be- 
tween 5-10 people. Since Ashano and team’s work focuses on specific 
features within an existing product, the prototyping, testing, and iter- 


ating process continues until the system feels refined and complete. 


Once a prototype is ready for development, the team will update the 
PRD again with mentions of any major changes to the interaction 
models and any links to new prototypes. As the developers build 
out the feature, the design team revisits the epics, user stories, and 
backlog for their next sprint. 


“UXPin remains the hub of our design projects,” he says. “If you’re a 
business analyst, developer, or designer, you can visit the hub and 
see all the details. As we move into development, they can still easily 


check how the code reflects the visual specs outlined in the prototypes.” 


Conclusion 


Autodesk’s Tel Aviv team shows us that enterprise design doesn’t 
need to be bogged down by poor communication and mountains of 


documentation. 
For a more lightweight and strategic design process, consider the 
following takeaways: 


¢ Validate feature requests with early qualitative research (reviewing 
support tickets and user interviews) and quantitative research in 


analytics tools and surveys 


¢ Dedicate time upfront for discovery and ideation with half-day to 


full-day workshops aimed at defining the rough feature set 


¢ Treat documentation as a knowledge portal rather than a paper 


trail by linking out to further details 


¢ Prioritize prototyping for the most difficult interaction models. 


The Organic UX Design Process 


Slack 


Valued at over $3 billion dollars with 600,000+ paying customers at the 


start of 2016, Slack is on a mission to humanize team communication. 


Just as Slack aims to improve people’s working lives through simpli- 
fication, it has also inspired an internal design process that mirrors 


this same free-flowing, organic approach to work. 


& slack 


Team communication 
for the 21st century. 


Channels 


@ policy 
ifety 


Direct Messages 
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The 400-plus employee company has a rare internal resource: a huge, 
constant pool of employees to user test with. Since all employees across 
the company dogfood Slack every day for 8+ hours a day, the Slack 
design team enjoys unprecedented access to constant user feedback 


and an intimate knowledge of the product. 


As a result, Slack’s design process mirrors the open, constant com- 


munication that the company was created to provide. 


From “A Vaguely Defined Problem Statement” to Product 
Brief 


Diogenes Brito, Product Designer and Engineer at Slack’s San Fran- 
cisco HQ, explains that most product ideas and feature requests start 
as “a vaguely defined problem statement” driven either by customer 
support tickets, feedback within Slack’s product channels and social 


media, or the company’s own product teams. 


Diogenes Brito, Product Designer and Engineer at Slack 


As one of the first steps in solidifying the project, the product manager 


and designer meet together to record ideas in one place. 


This initial document is a product brief that, as Diogenes says, is “re- 
ally about the spirit of the project, seeking to define the core goal and 
the nuances of the problem” so everyone has the right context for 
the follow-up kick-off meeting. The brief is in fact a living document 


which will evolve throughout the entire process. 


Indeed, while the core of the brief will stay the same once the project 
details are finalized, the brief becomes a focal point for design re- 
views and serves as an artifact of all that was done once the project 
is complete. It will even be used as the core asset for final executive 


review. 


The brief not only consolidates ideas down in one place but it also 
gathers constraints. 

Questions covered in the brief include: 

¢ What does the team care about the most? 

e What is in scope, and what isn’t? 

¢ What does success look like, and how will we measure that? 
“The brief is not prescriptive but more about asking the right ques- 


tions so we can explore in the right way, knowing the boundaries of 


the problem,” Diogenes explains. 


The Kickoff 


Once the brief is ready, the lead designer and product manager will 
hold a kick-off with the larger team. At this point, some preliminary 
ideas may be covered (and the designer may have completed some 


exploration with rough mockups or wireframes to act as a visual aid). 
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Regardless, at the kick-off, the team always reviews the entirety of 
the brief to ensure everyone fully understands the project and can 


air their core ideas and concerns. 


The kick-off helps everyone understand the design problems and 
goals, while also discussing any burning ideas. The kick-off is not 


meant as a free-form brainstorming session. 


Pair Design 


Once the kick-off finishes, designers and developers begin their ex- 
ploration and specification in tandem, checking in with each other 


in informally throughout the process in Slack. 


What is formalized is that designers always work in pairs, with one 


acting as the lead designer. Diogenes compares the relationship to 


the tennis stars Serena and Venus Williams, noting they are both 


amazing but one person is usually leading and serving. 
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“Pair design gives you a partner in crime to help you explore ideas 
more,” Diogenes explains. “It’s two people with similar or comple- 
mentary skills riffing off each other. Plus when you have two people, 


it helps you get unstuck faster when you hit a roadblock.” 


Both designers work on different design problems, but regularly 
brainstorm concepts and cross-pollinate ideas. Other team members 
may also involve themselves with the pair for consensus-building and 
informal brainstorming, but the team prefers impromptu activities 


to formally scheduled workshops. 


While the designers are exploring concepts, the developers are also 
exploring relevant parts of the codebase and overall technical con- 
straints. Once the two groups feel confident about their understanding 
of constraints, the whole team will hold a “post-kickoff” to review 


the product and technical requirements. 


Following the post-kickoff, design critiques happen twice a week. 
When a designer feels ready, they bring their work for feedback from 
the larger product team. While the larger team may offer feedback to 
the design pair, the “lead” designer remains the clear point of contact 


with the product manager. 


This point-person remains in place all the way through final design 
review, which includes product leadership and the CEO Stewart 
Butterfield. 


Freedom in Design Tools 


Instead of following strict protocol, Slack designers alternate between 
sketching and low and hi-fi prototypes when designing, using the 


right tool for the problem at hand. 


“The big thing for us is not whether we do a wireframe, mockup, or 
high fidelity prototypes,” Diogenes explains. “It’s about thinking about 
the question and using the best tool to arrive at the answer with the 


least amount of work.” 


For example, when Diogenes was working on a new auto-complete 
feature, he created a number of low fidelity prototypes to answer 
questions around the core interaction model. But when he encoun- 
tered tricky micro-interactions, he would build working prototypes 


in code to finalize the details. 
“Sometimes we can go right to design from sketching because we 
know our product so well.” he says. “We use whatever tools we are 


the fastest in-and that varies from paper, Keynote, HTML, to a col- 


laborative design platform depending on the project.” 


Designer Pro Tip 


When conducting a beta test, consider creating a Slack channel 


to simplify collecting feedback from users. During our redesign, 


User Researcher Ben Kim invited all 50 initial beta testers into a 
dedicated Slack channel. Every day, feedback was consolidated 
into a Google Docs spreadsheet with patterns summarized in a 


beta usability report. 
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Dogfooding and Usability Testing 


At Slack, usability testing is not usually a separate item in the design 
process. Instead, user testing is ongoing because of their massive 


internal user base. 


For example when the team decided to add voice calls, they designed 
and then released the feature internally, rolling it out very slowly in- 
house and then to an external beta before eventually to the whole 


user base. 


“We use our intuition,” Diogenes explains, “But it is finely tuned be- 
cause we all use the product for hours every day. User feedback is 
also regularly trickling in from outside of the company, and everyone 


serves weekly support shifts to better empathize with customers.” 


Indeed, within the walls of Slack HQ in San Francisco, the design 
team can test different user scenarios with its own departments. 


Each department acts as a microcosm of the larger customer base. 


For example, designers can learn more about how to improve Slack 
for finance teams by observing and gathering feedback from its own 


finance department. 


In addition to dogfooding, they also regularly prioritize a steady 
stream of feedback as it trickles into their customer support Slack 
channel. That said, when they do embark on brand new features 


or new audiences - such as international or enterprise-sized teams 


— the design team will conduct generative field research and more 


traditional moderated user testing to expand their knowledge. 


“Our company is like a 24/7 lab for us,” Diogenes adds. “And because 
we are all in the product all the time, no issues can just get swept 


under the rug.” 


Sprint to the Finish 


Once design is complete, the team moves to a development sprint 
model. Nonetheless, sprints remain flexible in case unforeseen 
challenges appear. By the time the product team reaches the sprint 
stage, most design work is done and the designers focus on offering 


support and quality control. 


Aside from constantly communicating via Slack, the team also holds 


standups in their channels or in-person as needed. 


“Transparency is key to our product and our culture,” Diogenes says. 
“These same core values inform our design process, making it truly 
organic and effective. And because we use Slack every day ourselves, 
new ideas keep coming every day — that’s a serious competitive ad- 


vantage.” 


Conclusion 


Slack’s organic design process shows that structured design isn’t the 
option for startups and enterprises. Flexible processes for concept 
exploration paired with structured development can deliver suc- 
cessful products, so long as regular research and testing validates 


the progress. 


In closing, we offer the following takeaways: 


¢ In a product brief, don’t prescribe the solution. Focus more on 
describing the context around the problem and suggestions for 


various strategies. 


¢ After the initial product kickoff, allow the team freedom to explore 
concepts and discover constraints. Merge development and UX 
insights by then holding a post-kickoff review to formalize con- 


straints. 


¢ Ifyour team structure allows, consider pair design for richer idea 


generation and faster problem-solving. 


¢ If your company’s employees are similar to your target users, reg- 
ularly dogfood the product for guerilla research. Internal feedback 
and testing builds a solid foundation of usability knowledge that 


you can expand through further field research. 
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Kaplan Test Prep 


Founded in 1938 as a tutoring business out of a New York apartment 
basement, Kaplan has since grown into a $2.1 billion-dollar company. 
Adaptive learning technology now powers all of its digital test prep 
products, delivering a personalized curriculum tailored to each stu- 


dent’s strengths and weaknesses. 


Supporting over 90 different types of college and postgraduate stan- 
dardized tests, Kaplan Test Prep’s product design group is responsi- 
ble for catering to multiple student personas and platforms across 


various business groups. 


As Lead Digital Product Designer, Laura Kershaw manages and men- 


tors a design team for Kaplan’s Test Prep division. 


When it comes to digital learning products, the team’s challenge lies 
in balancing templatization versus personalization. For example, 
someone studying for law school behaves differently than someone 
applying to medical school - and even within these groups there are 


varying behaviors. 


Laura Kershaw, Lead Digital Product Designer at Kaplan (left) 
collaborating with Caroline Romedenne, UX Researcher 
To deliver personalized experiences on quick timelines, Laura and 
her team follow a balanced design process based on three guidelines: 
Agile collaboration, a mobile-first approach, and regular usability 
testing. 


Research, Data, and Ideation 


At Kaplan, ideas come from multiple sources: customer feedback, 


internal teams, and external trends and business opportunities. 


Kaplan has learned over the years to balance user research, user 
data, and internal idea generation. Since research alone won’t drive 
innovation, internal teams across Kaplan can suggest changes based 


on external trends and opportunities. 


For example, ona recent project, Laura’s team needed to work through 
a concept aimed at motivating students. Her first step was to explore 
gamification options with a product manager with gaming industry 
experience. From there, they pulled in another product manager 
who works with a larger platform to vet their ideas, then spoke with 
a larger group (product owner, 2 PMs, lead API developer) for buy-in 


on the proof of concept. 


At this point, a dedicated user researcher dove into a treasure trove 
of insights gleaned from student surveys, app usage data, and user 
interviews. The insights not only helped the team understand the key 
pain points for users and the business, but also started establishing 


creative boundaries that later became formalized requirements. 


Meanwhile, Laura’s team might vet the idea further through explor- 
ative workshops with the whole team. In the case of the gaming idea, 


her team tried the following affinity diagramming workshop: 


1. Send an agenda days before informing all 6 participants of the 
design problem (How can we better motivate users?). Ask the 
participants to send examples of two mobile apps that reflect 


strong incentivization. 


2. On the day of the workshop, start the exercise with a fun game 
to create an open atmosphere. In this case, the team played the 
Heads Up game on their mobile devices instead of physical cards. 


10 minutes. 


3. After the warmup, every person on the team explains their likes 


and dislikes for the two mobile apps they selected. 30 minutes. 


4. Laura notes everyone’s reasoning and maps out patterns into 
categories. In this case, she ended up with 6 categories. 10 min- 


utes. 


5. Laura encourages the team to now write down ideas for each of 


the 6 categories. 10 minutes. 


6. The team discusses their ideas in each category. 15-20 minutes. 


After the workshop, Laura snaps photos of the results and shares 


with the larger group. 


The team then reviews the ideas against the user research and pri- 
oritize them for design sprints. The team prioritizes ideas with the 
highest user value and business value. Meanwhile, lower priority 
ideas move to a backburner board, which acts like a backlog for fu- 


ture exploration. 
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“Product managers don’t just attend workshops to take notes,” Laura 
explains. “They add a lot to the process as active contributors to our 
decisions. Everyone comes in with a different background and you 
never know where great ideas will come from.” 


After initial brainstorming, the team schedules UX sprints for deeper 
exploration and implementation. 


The UX Design Sprint 


At Kaplan Test Prep, the first half of the UX sprint focuses on con- 
ceptualization, while the latter half focuses on refinement and im- 
plementation. 

Documentation remains lightweight, with formal product require- 
ments acting as guidelines. For further specifications, the team will 


check their annotated prototypes. 


A 5-day sprint would look like the following, with days stretched out 


as needed: 


e Day One/Day Two: Small teams start sketching ideas on paper, 
based on data from the team researcher and the prior brainstorm- 
ing session. During the process, designers might ask questions 
about API and validate ideas against the scope. Meanwhile, product 


managers start formalizing the product requirements. 


e Day Three: After a few flows are sketched, the team will create 
paper prototypes to test with 10 students at the Kaplan office. 
Based on user validation, the team will also update product re- 


quirements as needed. 


¢ Day Four’ Five: This next step really depends on the type of project.. 
If Laura’s team is working with an existing product, they might it- 
erate their paper prototype based on feedback from students. They 


also might pull aside a bite-sized idea for a separate sprint cycle. 


It’s important to note that the product requirements are flexible. To 
allow for creative exploration, designers are empowered to work 
slightly outside of the specifications — as long as they collaborate 


closely with the product manager. 


After the first 5-day sprint, the next sprint will add fidelity and move 
towards implementation. The team will turn their paper prototype 
into a digital lo-fi prototype, test with 5-7 students, then iterate to 


higher fidelity. The more refined the design becomes, the less users 


the team involves for usability testing. 
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With a hi-fidelity prototype, the team will test with 5 students to ver- 
ify that the UI remains understandable (e.g. CTA copy is meaningful, 
graphics are consistent, and micro interactions are seamless. ). For 
both the lo-fi and hi-fi prototypes, the team simply visits a local Ka- 
plan testing center and offers Starbucks gift cards in exchange for 


10 minutes of testing per student. 
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“We really see the sprint process as a framework, not something set 
in stone,” Laura explains. “The most important thing for us is constant 


user testing to validate our ideas.” 


The True Meaning of “Mobile-First” 


Whereas “mobile- first” often simply means working from a product 
at a smaller canvas size and then scaling to bigger form factors, the 


Kaplan approach is about overall function. 


With mobile usage growing in the education sector, the Kaplan team 
spends significant time developing meaningful standalone (and com- 
panion) experiences. It’s one thing to create a product that responds 
to multiple devices sizes and orientations, but it’s quite another to 
design something that presents the same information in the most 


intuitive format for the device. 


Throughout the design sprints, Laura focuses first on designing a 
compelling mobile experience that everyone then scales to larger 


form functions. 


For example, a student won’t take a 4-hour exam on their mobile 
device, but they would complete a quick 10 minute quiz. With this 
in mind, she builds the core mobile feature set, then works with the 
rest of the team to grow the experience to tablet and desktop. This 
method also allows Kaplan to move faster with proof of concept be- 
cause they can test ideas out on a smaller scale, rather than rolling 


it out onto a larger course-wide product. 


“Because our process is mobile-first, it forces people to think more 
creatively about how to tackle the problems they want to solve,” 
Laura says. “This results in better products for our students on all 


devices and computers.” 


The Role of Collaborative Prototyping 


Likewise, Kaplan is a strong believer in collaborative rapid prototyp- 
ing to quickly iterate designs. With each iterative prototype that is 
developed (for web, mobile, or other platforms), the team recognizes 
more features or elements that might make sense on one platform 


over another and modify the design in order to best accentuate. 


By removing the dependency on reading arduous documentation, she 


and the team can quickly communicate and trace product decisions. 
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They’re freed up to focus more on designing, validating, and iterating 


the core interaction models. 


“UXPin gives us living documentation of our projects,” Laura says. 
“You can just check on prototypes to see how things are going. You 


don’t need to read ten pages of technical documentation.” 


Co-Located Product Teams 


Laura came to Kaplan with a background in design and architecture. 
Aside from product design, Laura’s role also includes mentoring and 


leading a group of designers as the acting Creative Director. 


Since the culture and employee development programs are anything 
but siloed, one of Laura’s initiatives is redesigning the office to move 


designers and developers out of their separate bays. 


Whereas someone may have started at Kaplan as a web UX special- 
ist, after a few months, they are exposed to other elements of design 
including UI for web, UX for mobile, and perhaps even some anima- 
tion work. Due to the open culture at Kaplan Test Prep, the CEO John 
Polstein himself might even attend some of the design collaboration 


sessions. 


“Everyone I work with is extremely talented and has the potential 
to be amazing with the right influence,” says Laura. “If given the 
opportunity to learn and grow, nothing can stop you. The more you 


know, the more valuable you are, and the better you work as a team.” 


Conclusion 


Kaplan’s product design team shows us that creative freedom and 
Agile UX shouldn’t be enemies. Through collaborative brainstorming, 
regular user validation, and scalable design sprints, the team can 


better preserve creative integrity amidst fast timelines. 
For an efficient yet creative design process, consider the following 
takeaways: 


¢ Explore product ideas with parallel paths of user research and 


ideation, then converge afterwards to define requirements. 


¢ Casual ideation workshops with a clear agenda helps remove fear 


of “dumb ideas”, encouraging feedback from quiet team members. 


Product documentation acts as guidelines, with some flexibility 


allowed for creative freedom. 
Collaborative prototyping minimizes paper-trail documentation. 


Test with users as prototype fidelity increases (more users in the 


beginning, less is acceptable later on). 


Mobile-first product design can help test ideas quickly on a smaller 


scale. 


The Power of Swarm Design 


Sumo Logic 


Based in the Bay Area with 250+ employees and $161 million in ven- 
ture capital funding, Sumo Logic serves some of the top enterprises 
in the world. The company’s analytics platform visualizes more than 
100 petabytes of data per day, helping businesses harness the power 


of machine data to streamline operations... 


To make the data actionable for customers, Sumo Logic has invest- 
ed heavily in its own internal UX team to bring a “consumer-grade” 
experience to the enterprise. In 2015, they hired their first UX team 
comprised of design leaders, interaction designers, visual designers, 


and UX architects. 


In the beginning, their VP of Design Michael Peachey also defined 
a Clear vision for the UX team: “A Sumo Logic organization where 
each of us are connected deeply and emotionally to the individuals 
we serve." This foundation still drives the purpose of all their collab- 


orative design within the organization. 


Real-Time System Insights 


Photo credit: Sumo Logic 


Across the organization, the design process is defined by design think- 
ing: creating a hypothesis, testing with users, gathering feedback and 
improving. For Design Director Daniel Castro and team, their unique 
“Swarm” sessions have been the key collaborative activity connecting 


all the discovery, design, and iteration. 


As a result, the product team builds a design culture through immer- 


sion rather than preaching. 


Discovery 


One of Sumo Logic’s most important first moves is reaching out to the 
customer success team, who they consider their “brothers in arms”. 
Daniel tries to interview at least 3-5 users directly to understand 


their pain points and needs before doing anything else on a project. 


After interviews, the design team starts visualizing the feedback and 


insights. 


Daniel and the team will draw out the customer journey through 
spreadsheets, flow charts and even cartoons. They’ll also filter through 
their early concepts and vet them with a larger group of engineers, 


product managers and customer success team members. 


Photo credit: Customer journey map created at Sumo Logic by Nitesh Jain 


For deep exploration of the problem, they might hold a focused 


“Swarm” session lasting anywhere between 2-5 days. 


Once the team starts to see the requirements shaping up, the PMs 
will start planning the project so that the design team can work one 
sprint ahead of development ( e.g. Sprint 16 is dedicated to visual 
design that developers build in Sprint 17). The product team also 
plans for a steady cadence of usability testing (e.g. Sprint 15 is test- 
ing, Sprint 18 is testing) so that the PM can recruit users and the UX 


team can run the tests. 


Once the team aligns to a solid plan, the team will hold a quick design 
kickoff with just a basic agenda-—no formal design briefs allowed. At- 
tending this first meeting are the designers, product managers and 


UI developers, who are an integrated part of the product team. 


Along the way, they will create some early product specs, but they 
prefer prototyping to create “living documentation” instead of drafting 
thick specs documents. Since UI developers are part of the UX team, 


the close collaboration minimizes the need for paper trails. 


“Documentation doesn’t need to live in a document. You can be nim- 
bler, like Slacking your team a screenshot of your whiteboard,” Daniel 
saysid. “To convey more detail, Ill create a quick UXPin prototype 
and share with the team instead of marking up a huge specs docu- 
ment. I can just drag and drop objects from the dozens of libraries to 
convey the concept. The platform really shines at helping us create 
collaborative visualizations to help PMs and developers understand 


the horizontal and vertical requirements.” 


After this discovery, the team asks themselves if the prototyped 
concepts feel viable and feasible. If the answer is no, they’ll dive 
into another sprint for research and exploration (e.g. “Sprint 0”). As 
Daniel explains of the discovery process, “A designer’s deliverables 


is answering these questions, not generating paper documents.” 


Designer Pro Tip 


When planning design sprints, make sure you allow for user re- 


search beyond the initial Sprint 0. Work with the product owner 


to plan at least 1 hour of user research per weekly sprint. 


As Jared Spool explains, increasing the “exposure time” to users ts 
the closest silver bullet he’s discovered for product improvement. 
In fact, one 10-member product team generated a list of 350 quick 


fixes after visiting 12 customers for 2 hours each. 


User Flows Personas Prototypes 


Created in UXPin: Managing assets and project status for a recent design sprint 


Deep Design 


Sumo Logic’s design discipline centers around the idea of diving deep 


into chunks of work. 


Once concepts are approved to be fleshed out further, the engineering 
and product teams start looking at their overall projects and breaking 


them into smaller bites. 


Within this approach is the sub-discipline of the design-the “Swarm” 
or “UX Palooza” as they are also called. While the team generally 
conducts Swarms early in the product development process, they 


treat the activity as a tool that works even later in design crunch time. 


Photo credit: Daniel Castro of Sumo Logic. Swarm session. 


Every month, the UX team clears their calendar for 2 days (and up 


to 5), focusing on a specific problem that will help move the overall 


project forward. They will also notify stakeholders and subject mat- 
ter experts to set aside a few hours of time to give feedback on ideas. 
The Swarms evolved from work sessions where the UX team would 
spend ~3 hours with a subject matter experts churning on a prob- 
lem. These sessions were so successful that the design team ended 


up formalizing the process. 


“The Swarm is not a blue skies session; it’s more like a war room,” 
Daniel explained. “We gather everyone together, regardless of what 
project folks are working on, and put them on task to solve a certain 
thing. By focusing intently as a team, we can move projects forward 


and overcome obstacles faster than scattered 1-hour sessions.” 


1. The Swarm Process 

The Sumo Logic team communicates via Slack, so the first step is 
to align everyone’s schedules, give the Swarm a name, and build 
some major hype (and therefore excitement) around the project. 
The team prefers holding Swarms earlier in the week, such as 
Tuesdays and Wednesdays (rarely Mondays for a million obvious 
reasons) so that Thursdays and Fridays are dedicated to hashing 
out the details. 


As noted, all designers jump into the project and help (even if they 
aren’t already part of the overall work), which lets fresh thinking 


be introduced into the mix. 


The agenda for the swarm will include two to three initiatives at 


most, with the goal of coming out on the other end of the second 


day with something concrete. While the design team is split into 
two smaller teams to accomplish these goals, the teams are en- 


couraged to cross-pollinate ideas. 


Daniel also noted that the key is strategically inviting stakeholders 
to these sessions-they don’t need to be present for the whole time. 


Focus is the absolute key to preventing design by committee. 


A typical 2-day Swarm looks like this: 
Day One 
¢ The day starts with a quick debrief. 


¢ Two smaller teams are formed to tackle two projects. Since 
everyone works in the same room, cross-pollination can or- 
ganically happen. As Daniel explained, “They hear each other’s 


ideas and evolve their designs together.” 


e First Check-in: Typically after lunch, both teams meet and 
share their progress so far, discussing obstacles and potential 
solutions. They may also invite outside stakeholders and SMEs 


for quick feedback. 


¢ Teams return to work sketching or lo-fi prototyping in plat- 
forms like UXPin. Feedback surfaces in real-time within their 
dedicated Slack channel. 


¢ Second Check-in: Around 4PM, both teams re-huddle and quickly 
plan their actions for the next day. At this point, the check-in 


focuses on tracking progress rather than decisionmaking. 


“Day one gives you a good sense of what day two will look like,” 
Daniel says. “By 5 p.m. you're fried but excited because the whole 
team is working together, keeping it light and fun while making 
major progress. The process has really made us a collaborative 
group. Designers, developers and product managers alike have 


been sucked in along the way.” 


Day Two 


e The day starts with a sanity check on expectations. The second 
day, as Daniel noted, is “all about the finish line.” For Swarms 
held later in the design process, the team spends time talking 
about what kind of visual designs or hi-fi prototypes they need 


to refine the concepts from the first day. 


¢ Third Check-in: The final checkpoint of the swarm. Typically 
subject matter experts will return for to give feedback on the 


refined prototypes. Any fine-tuning will then take place. 


e The last meeting is a show and tell, which is less about input 
than sharing to a larger audience including the VP of Design 
and other executive stakeholders. The team guides stakeholders 
to focus on the overall strategy rather than design minutiae. To 
dive into feedback in more detail with vocal stakeholders, the 


team will hold ad-hoc 1:1 sessions to give them the right forum. 


“You often hear how design doesn’t get the same seat at the table 
as engineering or sales do at the enterprise level, but Sumo Logic 


is an example of the complete opposite,” Daniel says. “The fact is 


that by publicizing our Swarms and inviting the larger company to 
our show-and-tells, design has achieved amazing visibility within 
the entire organization. We immerse the company in design, letting 


us change the culture by experience rather than trying to preach.” 


Sumo Logic prototype created in UXPin for their Unified Logs Metrics product 


By holding high-visibility Swarms, the UX team is able to showcase 
solutions to business problems in as little as 2 days at any point 
in the product development process. In doing so, the quick wins 


also earn buy-in for additional research or iteration. 


UX is therefore perceived less as a “soft” social science and more 


as a bottom-line force multiplier. 


. Iteration & Testing 
After the Swarm session, the design team returns to the sprint 
schedule. They will continue iterating and testing their designs 


with users. 


Sumo Logic is also unique in how they run their usability testing 


sessions. 


For users who want to test products but can’t be accommodated 
in the schedule, the design team will actually invite them to ob- 
serve tests alongside the designers. In doing so, they’ve revealed 
surprising insights. For example, a test participant might say out 
loud that they love seeing a ton of data in a new dashboard, but 


the 3 users watching might mention the density is overwhelming. 


Once everyone is comfortable with the design, the project moves 
into development sprints. The UX team stays involved with devel- 


opment as the project moves toward the finish line. 


Even in development, sprints still account for usability testing. 
Given that Sumo Logic launches features incrementally, the team 
can check in and iterate regularly, running additional customer 
interviews and staying in close contact with customer support 


throughout the process. 


Conclusion 


In closing, let’s summarize the takeaways from Sumo Logic’s design 


process: 
¢ Participatory design is the strongest form of UX evangelization. 


e Planning for design work a sprint ahead of development allows 


more time for work sessions and ad-hoc user research. 


¢ More focused workshops (e.g. Swarms) improves visibility and 


efficiency of the product team than scattered work sessions. 


e Inviting vocal stakeholders to 1:1 feedback sessions isolates risk 


of design by committee. 


“Communication is the bloodline of design,” Daniel says. “You can make 
the greatest design, but if you communicate poorly, your ideas will 
fail. At Sumo Logic, we’ve built a culture where designers, developers 
and product managers work together, collaborating every step of the 
way in a focused manner. The result has been great products for our 


customers and a really rewarding work experience for our teams.” 


Structured Participatory 
Design in the Enterprise 


3M Health Care 


With $30 billion in revenue and 90,000 employees worldwide, 3M has 
built a thriving business over the past 100+ years on one core princi- 


ple: applying science in collaborative ways to improve people’s lives. 


The 3M Health Care Business Group’s UX team follows the same 
core values of collaboration and transparency in their design work. 
Their projects include physical products such as smart inhalers and 
digital products ranging from enterprise medical coding software 


to internal sales tools. 


Andy Vitale, Lead Interaction Designer at 3M Health Care 


“Our design approach is to regularly connect with colleagues in other 
disciplines like marketing and R&D as strategic partners,” says Andy 
Vitale, Lead Interaction Designer at 3M Health Care. “When our UX 
and business teams work together with clear vision and goals, we 


find greater success through a shared commitment to authenticity.” 


Andy’s team currently supports 6 different divisions of the Health 
Care Business Group at 3M; Health Information Systems (e.g. billing 
and hospital quality of care), Critical and Chronic Care, Food Safe- 
ty, and Drug Delivery Systems, Infection Prevention and Oral Care 


(dental and orthodontic). 


His small team tackles a big list of projects, supporting both new 


products and long-established brands. 


In a complex space where large companies struggle with scaling UX 
methodologies, 3M is a refreshing contrast to the waterfall-focused 
and engineering-driven enterprise. Their product development pro- 


cess reflects one of the most mature UX models we’ve seen to date. 


Due in part to the strong design culture built in the past few years 
since Chief Design Officer Eric Quint joined the organization, 3M 
Design follows a disciplined UX process rooted in co-design and cus- 


tomer validation. 


“Show, don’t tell” is a philosophy that drives all the participatory de- 


sign activities you’ll see below. 


Team Structure 


Andy Vitale’s 6-person UX team for 3M Health Care covers the fol- 


lowing disciplines: 


e Interaction Design 

e User Research 

e UX Strategy 

¢ Information Architecture 

e Visual & UI Design 

¢« Content Strategy 

¢ Front-End UX Development 


Each team member’s skillset is T-shaped. While they may specialize 
in certain areas, each person can also help cover other competencies 
as needed. Andy, for example, specializes in interaction design and 
user research but can also assist when needed in some of the other 


design disciplines. 


Initial Research 


At 3M, product and feature solutions can come from multiple sources, 
including the business, technical or design teams. The 3M Health Care 
Design Officer also meets with the division leadership to prioritize 


projects based on resourcing, current status, and expected impact. 


Once a project starts, the first step for the UX team is to review any 
existing research for context around the design problem. Stakeholders 


provide the following information to designers on an ongoing basis: 


e Market research — Information around the market landscape and 


how existing or future 3M solutions could fit. 


e Industry insights research — Information specific to the business 


division that identifies opportunities. 


¢ Voice of customer research — Any initial user research conducted 


by the business. 


By reviewing the three sources of research, the design team better 
understands the current status of the project and the desired target 
users. The information also provides talking points for stakeholder 
interviews and helps uncover points of validation for future field 


visits with customers. 


Stakeholder Interviews 


After reviewing the existing research, Andy’s team prepares a short 
discussion guide for stakeholder interviews. The stakeholder inter- 
views help the team understand business requirements and informs 


their first draft of the design brief. 


Stakeholder interviews are usually conducted on an individual basis, 


lasting between 45-60 minutes per session. Occasionally, the team 


might conduct department interviews instead (e.g. 2-3 marketing 
people in one interview), but they don’t hold cross-departmental 


group stakeholder interviews. 


The 1:1 format allows Andy’s team to thoroughly explore each per- 
son’s subject matter expertise and vision of success for the project. 
If more information is required, the designers are free to schedule 


follow-up interviews. 

When conducting stakeholder interviews, consider Kim Goodwin’s 
guidelines for each department: 

¢ General Stakeholder Interview 

¢ Marketing Stakeholder Interview 

e Engineering Stakeholder Interview 

e Sales Stakeholder Interview 


e Executive and SME Stakeholder Interview 


Customer Journey Mapping Workshops 


With a clearer picture of business requirements, the UX team con- 
ducts a customer journey mapping workshop to plot out the user’s 


perspective before, during, and after service: 


e Emotions — Any moments of satisfaction, anticipation, and frus- 


tration. 
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¢ Touchpoints — Every step of the journey that the user interacts 


with the company 
e Channels -— Where interactions occur (e.g. online, mobile app, etc.). 


¢ Moments of Truth —- Any particular touchpoints or actions that 


generate lasting frustration or satisfaction. 


The designers typically map the journey out on a large board, while 
stakeholders add their thoughts with Post-it® Notes next to each step. 
Together, the team then discusses all of the perceived roadblocks and 


opportunities. 


Baty, 


Design at 3M Health Care 


“We try to build the customer journey collaboratively before we get 
too far ahead of ourselves,” Andy explains. “Before we talk to cus- 
tomers, we want to make sure we’re all on the same page internally 


as far as understanding the problem and opportunity.” 


After the first half-day “all-hands” customer journey mapping work- 
shop, the design team will then follow up with two-hour sessions as 
needed. Once the whole exercise is complete, the UX team sends a 
summary email prioritizing the project goals and any newly-revealed 


constraints. 


For efficiency, Andy recommends first sending out a clear agenda 


with timeboxes for each part of the workshop. 


Contextual Inquiries 


Following the customer journey mapping, the UX team conducts on- 
site field research, which could last up to several days with multiple 


users at different organizations. 


Because Andy’s team designs enterprise products, they speak with 
the end-users, managers, and software purchasers. The goal of the 
on-site visits is to validate all the insights generated so far in the ini- 


tial research analysis and customer journey mapping. 


“Empathy mapping is a critical part of our work,” Andy explains. 
“From the beginning, we’re doing customer field visits to observe 
our users in their natural habitats. We’ve found bringing customers 
in for interviews wasn’t enough—we need to be where they live and 
work to truly understand their issues. And we don’t want to just hear 


their pain points, we want to hear their needs and desires.” 


During onsite visits, the team gathers customers together for con- 
versations about their needs and solutions based on a prepared 
discussion guide. Andy’s team typically stay onsite for a few days, 
with hour-long group discussions and many 1:1 observations (30-60 


minutes) of individuals at work. 


“We like to observe our users doing their normal tasks,” Andy says. 
“They tend to get comfortable with us looking over their shoulder. 
It’s just so important to understand the reasoning behind what they 


do rather than just their steps.” 


At the end of each day, all of the designers will sort their notes into 
a shared template. The designated research lead then sorts through 


the data to remove duplication and identify patterns. 


Building the User Personas 


Once the team returns to their office at 3M, the design team updates 
assumptions by transforming the new information into personas for 


user groups. 


These personas are shared with the business team, and everyone 
works together to align on accuracy. Depending on the project time- 
line and status of updates, the personas can range in detail from 
lightweight to highly detailed. 
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At this point, the team will also update the design brief to reflect new 


user requirements uncovered in the field visits. 


“By looking at these personas together as a design team, we can see the 
overlaps in needs between different user groups,” Andy says. “From 
there we can begin sketching solutions around the initial hypotheses 


and core features.” 


Once the design team has finished more refined sketches of the fea- 
ture ideas, they present the concepts to key internal stakeholders 
with all consolidated research information available to everyone in 


a cloud folder. 
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Design at 3M Health Care 


The Design Brief 


All the research will ultimately feed into the formal design brief, 


which serves as a rallying point for design. 


While the first draft was created after the stakeholder interviews, 
the design brief takes final shape after the field research. The design 
brief allows for alignment on design direction based on all the prior 


activities: 

e Business needs explored through stakeholder interviews 

¢ User needs validated through field research 

¢ Overall UX principles based on brand guidelines and sketching 
¢ Project timeline 


Once all internal stakeholders agree to the brief, the team dives into 


more detail by prioritizing features. 


Feature Prioritization 


With involvement from the developers, the UX team prioritizes all 


features based on feasibility and impact against the design brief. 


A spreadsheet acts as an early product roadmap by breaking down 
the features by category, owner, and schedule (in-scope, later sprints, 
or move to backlog). The team also includes tabs for technical, UX, 


and business notes. 


In order to visualize requirements for stakeholders and developers, 
the UX team also creates atomic models (in Illustrator) mapping out 
the page flows and taxonomies. Since the models will evolve, the 
team doesn’t want to overwhelm stakeholders with a complex tree 
of 50-60 features across the whole system. Instead, designers only 


share high-level interactions between 10-12 core feature sets. 

Once the team finishes their work, they hold a 2-hour workshop for 
stakeholder feedback on the following items: 

e Spreadsheet of prioritized features 

¢ Relationships between feature sets outlined in atomic models 

e User research and market research supporting the above decisions 
While priorities may shift, Andy has found that bringing along re- 


search and referencing the journey map helps guide strong opinions 


towards a common understanding. 


“Storytelling is one of our greatest strengths as designers,” Andy says. 
“By explaining how each feature impacts the user along touchpoints 
of the customer journey map, we create a common reference point 
for stakeholders. They start to see how their decisions impact the 


user, and identify the path to the right solution.” 


For small projects, the spreadsheet and atomic models are generally 
sufficient as product and technical documentation. Ifa product needs 
to move through regulatory or legal review, a business stakeholder or 


product manager will need to create more detailed documentation. 


User-Validated Design Sprints 


Once full alignment is reached, the entire team schedules the design 
sprints. Earlier sprints are dedicated towards high-impact features 


and quick wins. 


Before the first design sprint starts, the team reaches out to a core 


group of users (typically 8-12) to schedule regular usability testing. 


3M Health Care’s UX team then follows an alternating 1-2 week sprint 
cycle of design and user testing for feedback and validation. Starting 
with low-fidelity prototypes, the design team increases the fidelity as 
their concepts begin to solidify and the users are more comfortable 


with the design sprint process. 


Design at 3M Health Care 


“We usually build and test prototypes within that 40-80 hour duration,” 
Andy says.”We understand our user’s time is valuable and appreciate 


that they are willing to spend time working with us.” 


The overall length of the project varies widely depending on wheth- 
er the project is an update to an existing product or an entirely new 


offering. 


The design and testing cycles typically happen in a “rinse and repeat” 
format before they move into development. To keep everyone on 


track, the whole team also participates in daily standups. 


For the sake of efficiency, the 3M Health Care team uses remote testing 
along with satisfaction surveys. Along the way, they communicate 
regularly with their core business team and adjust the design and 


technical requirements as needed. 


Despite the different project lengths and scopes, the commitment to 


customer testing and team collaboration helps define the final design. 


“Our basic methodology is always the same: we put the right people 
in the room, work together to solve problems, and make sure the 
customer’s voice is heard,” Andy explains. “The results are increased 
customer satisfaction and ultimately, a real seat at the table for UX 


to impact the organization.” 


Conclusion 
3M Health Care’s structured process shows how enterprise companies 
can practice collaborative design amidst complexity: 


¢ Check every design problem against initial research before diving 
into a full kickoff. 


e Validate existing research with on-site customer interviews. 


e Involve stakeholders in co-design sessions to sketch out ideas, but 


empower designers to make the key decisions. 


e Align the larger team to a formal design brief informed by market 


and user research. 
e Adjust design sprint length based on iteration stage. 


e Alternate each design sprint with a usability testing sprint. 


Next Steps 


Successful design processes can range from the more organic frame- 
work practiced by Slack to the highly structured process of 3M Health 


Care. 


As all these companies have shown us, great product design isn’t a 


result of the best process — it’s the result of the right process. 

If you found this guide useful, here’s some more resources worth 
checking out: 

¢ HBO’s New Shorthand for Design Collaboration 

e Lean vs. Agile UX: Is There a Difference? 

e UX Design Process Best Practices 


e The Guide to Agile UX Design Sprints 


UXPin 


ENTERPRISE 


Go) Create and Collaborate. 
Translate requirements into product features 
that resonate with customers. 


Simplify your Process. 
Centralize projects and people into one clear workflow. 


Empower your Team. 
Guide creativity with a common design language. 


Take a look 


